Subject: Latest FSMs + June AIW

From: [email-masked] (Paul Brittain)
Date: Sun, 22 May 94 19:17:27 BST

Steve

Apologies for being quiet on the net for a few weeks - I was busy implementing
things for a change!

I have a few comments and suggestions on what has flowed on the net, mostly
just clarifications to grey areas in the FSMs.

6611 FSMs/SSP Formats
=====================

We agree that the 6611 FSMs you have posted to ibmstandards should be used as
the basis for the standard. The following suggestions came up during
discussions within Data Connection:

-       Please document that the x1D 'Wide Area Hello' message used by MPNP 1.2
        is of infoframe length and does not have a control header.

        As a general point, we need to be careful about any SSP messages that
        may flow using just the INFOFRAME header as DLS partners will get out of
        synch on the TCP bytestream if they have different expectations for the
        size of header used for any message type.  This is unavoidable if the
        message length does not include the header, hence unrecognized message
        types can only be assumed to have Control Message headers.

-       Presumably the reverse is true for ENTER/EXIT BUSY and TEST CIRCUIT
        messages - i.e. they use Control Message headers?

-       Why send DATAFRAMEs in RESTART_PENDING/CIRCUIT_RESTART states instead of
        DGRMFRAMEs? Surely the whole point of the of the RESTART processing is
        that the circuit still exists (at least between the 2 DLSw boxes) so it
        should not be necessary to force matching by data link ID rather than
        circuit ID (or, depending on implementation, a 'broadcast' to all LANs).

-       Your CUR_ex/cs proposal will presumably require some change to the
        actions and state transitions during circuit setup.

-       The existing RFC is not specific about which of the Data Link
        Correlator, Port ID or Transport ID are allowed to vary on at which
        points during the circuit setup sequence.  MPNP 1.2, for example,
        requires the port ID from the CUR to be echoed in the ICR, and for
        Netbios circuits it does not fix the target data link correlator on
        the NETBIOS_NR, the analog of an ICR.

        We could specify that these fields must be saved from any message that
        flows with a control header, but that would lead to lots of unwanted
        overhead checking or saving unchanged correlators all the time.

        We would prefer to specify that these three fields cannot vary
        after the ICR/NR and RA flow and the circuit has been established.
        This implies that both ends must have established whatever data
        forwarding route they will use for a circuit by the time the RA has been
        received at the target.

        An alternative would be to allow the data forwarding path choice
        to be delayed until the CONTACTED flows.  However the lack of a
        'CONTACTED ACK' message makes it impossible to achieve a handshake at
        this point to exchange both ciruit IDs.

        We don't particularly want to add a 'CONTACT ACK', hence would like
        to propose that the RA is the last point for circuit ID setup.  However
        this does clash with the use of SSP by MPNP for Netbios circuits.
        We're not trying to force a change to the 6611 just for fun, but
        think the RA is the more logical point to effect the circuit ID
        handshake.

        Please feedback your thoughts on this point.

June AIW
========

I've only had time for a quick glance at your 'state of the RIGlet' mail.  It
seems comprehensive apart from the last point above, which I think should be
added to the open items list.

To start the ball rolloing on on these issues, here's some initial feedback:

-       We would like to see non-activation XIDs added (which doesn't look
        difficult!)
-       Do we need to include SIM/RIM support in the SDLC discussions?  If so,
        what about the use by FEPs of SIM extensions to LLC2 for microcode
        download?

Paul Brittain
Data Connection.